1. Field of the Invention
The invention generally relates to management of SAS wide ports. More specifically, the invention relates to methods and structures for efficiently validating transfer tags in the transport layer processing of a SAS controller.
2. Related Patents
This patent is related to co-pending, commonly owned U.S. patent application Ser. No. 10/920,984 filed on Aug. 18, 2004 and entitled SYSTEMS AND METHODS FOR FRAME ORDERING IN WIDE PORT SAS CONNECTIONS which is hereby incorporated by reference.
3. Discussion of Related Art
Small Computer Systems Interface (“SCSI”) is a set of American National Standards Institute (“ANSI”) standard electronic interface specifications that allow, for example, computers to communicate with peripheral hardware. Common SCSI compatible peripheral devices may include: disk drives, tape drives, Compact Disc-Read Only Memory (“CD-ROM”) drives, CD Read/Write (“CD-RW”), digital versatile disk (“DVD”) drives, printers, scanners, etc. SCSI as originally created included both a command/response data structure specification and an interface and protocol standard for a parallel bus structure for attachment of devices. SCSI has evolved from exclusively parallel interfaces to include both parallel and serial interfaces. “SCSI” is now generally understood as referring either to the communication transport media (parallel bus structures and various serial transports) or to a plurality of primary commands common to most devices and command sets to meet the needs of specific device types as well as a variety of interface standards and protocols.
The collection of primary commands and other command sets may be used with SCSI parallel interfaces as well as with serial interfaces. Examples of serial interface transport media and protocol standards that support SCSI command processing include: Fibre Channel, Serial Bus Protocol (used with the Institute of Electrical and Electronics Engineers 1394 FireWire physical protocol; “IEEE 1394”) and the Serial Storage Protocol (SSP).
SCSI interface transports and commands are also used to interconnect networks of storage devices with processing devices. For example, serial SCSI transport media and protocols such as Serial Attached SCSI (“SAS”) and Serial Advanced Technology Attachment (“SATA”) may be used in such networks. These applications are often referred to as storage networks. Those skilled in the art are familiar with SAS and SATA standards as well as other SCSI related specifications and standards. Information about such interfaces, media, protocols and commands is generally obtainable at the website http://www.t10.org.
Such SCSI storage networks are often used in large storage systems having a plurality of disk drives to store data for organizations and/or businesses. The network architecture allows storage devices to be physically dispersed in an enterprise while continuing to directly support SCSI commands directly. This architecture allows for distribution of the storage components in an enterprise without the need for added overhead in converting storage requests from SCSI commands into other network commands and then back into lower level SCSI storage related commands.
A SAS network typically comprises one or more SAS initiators coupled to one or more SAS targets via one or more SAS expander devices. In general, as is common in all SCSI communications, SAS initiators initiate communications with SAS targets. In particular, SAS initiators use a process often referred to as “discovery” to determine the topology of devices in the network (i.e., to discover other SAS initiators, SAS expanders and SAS targets). Once such information is known, initiators generally establish the first contacts with a given target device. The initiator issues an “open” request (i.e., a SAS OPEN address frame) to an identified SAS target to establish a first connection with the SAS target device. Once the first connection is so established, either the SAS initiator or the SAS target device may re-establish a connection. For example, a connection may be established initially by the initiator, closed after some transactions are exchanged, and then re-opened by the same initiator for a subsequent sequence of transactions. Or, for example, a SAS target device may have deferred processing of a transaction received from an initiator. At some later time when the SAS target is ready to proceed, the target device may “open” a connection back to the initiator that originally requested the deferred transaction.
In SAS protocol command exchanges, a SAS initiator device sends a command and associated data to a particular identified SAS target device. The command and data exchanged may be voluminous but the SAS specifications limit each frame to approximately 1 kilobyte. Thus a larger exchange must be broken into smaller frames and distributed over a number of frames. Further, since the SAS specifications permit multiple commands/data to be exchanged concurrently, each SAS command is identified with a set of field values that, collectively, uniquely identify the I/O being processed to which a sequence of exchanged frames are related. For example, in a SCSI application, the combination of an initiator device ID, a target device ID, a logical unit number (“LUN”) and a tag value (assigned by the initiator) is assured to uniquely identify a sequence of related frames all related to a particular I/O operation. As a matter of design choice, in a particular application, a unique TAG field value (or using the Target Port Transfer Tag (“TPTT”) field value) may provide a sufficiently unique ID to identify all frames related to a particular I/O request. Collectively the TAG and TPTT field values may be referred to herein as tag fields (or “transfer tags” or “tag values”). The specification for contents of these tag fields and their use in SAS transport layer processing are well known to those of ordinary skill in the art and are documented in the SAS specifications. In general, these tag values are provided in the headers of each transmitted/received frame so that the receiver may determine which command a received frame is associated with.
SAS specifications also allow for a wide port—a logical port comprising a plurality of ports aggregated to operate as one logical port. SAS specifications restrict use of the wide port such that at any given point in time, frames for a particular command may be transferred over only one of the multiple ports that make up the wide port at a time. Once one frame is completely transmitted (and acknowledged by the receiver), another frame may be received on the same port or another of the multiple ports of the wide port.
The SAS specifications for the transport layer processing calls for validation of frames to include validation of the tag fields exchanged in frames between an initiator and a target device. It is common in SAS controller implementations that the transport layer processing is performed by a single transport layer processing element —i.e., a general or special purpose processor programmed with software/firmware (programmed instructions) to perform the transport layer processing according to SAS specifications. Such a software/firmware implementation of a transport layer may also perform transport layer processing for a SAS wide port by coordinating with the multiple link layer processing elements for the ports that make up the wide port. Such a software/firmware implementation of a transport layer integrates the management of the multiple physical ports and their communication in the single transport layer processing element.
Where particular SAS controller embodiments separate the transport layer processing such that each physical/link layer is associated with a distinct transport layer processing element, such coordination for tag validation in wide ports is problematic. For example, some embodiments of SAS controller provide customized integrated circuits—one per link/transport pair—for controlling physical/link layer processing and for controlling transport layer processing in accordance with the SAS specifications. In such an embodiment, each transport layer is associated with a corresponding link/physical layer to define the processing of a single port. In a wide port application, the multiple custom circuits that control each of the multiple ports of the wide port would have to cooperate to effectively validate tags as required of the transport layer in the SAS specifications. For example, a first port of the multiple ports that comprise the wide port may receive the initial frame that defines the valid tag for a sequence of related, tagged frames. The other ports would potentially receive subsequent frames but without the knowledge of the valid tag defined by the first frame of the sequence. This level of coordination presents a problem for managing transport layer tag validation in SAS wide port applications.
In view of the above discussion, it is evident that there is an ongoing need for improved systems and methods for transport layer tag validation in the processing of SAS frames received over multiple physical ports of a SAS wide port.